Authors: Please fill out this form carefully and completely.

Reviewers: By approving this Pull Request you are approving the code change, as well as its deployment and mitigation plans.
Please read this description carefully. If you feel there is anything unclear or missing, please ask for updates.

What are you trying to accomplish?

In #3144 we managed to reduce the cost of an expensive recalc by using @property --dialog-scrollgutter { inherits: false }. This dramatically reduced the recalc cost of this particular bit of code.

However one thing we wanted to do - but failed to achieve in that PR - was to perform this calc as late as possible. Right now every page load (or thereabouts) that features a dialog causes this recalc. In #3144 we first tried to override the invoker function to do this during the click of the opener button, however there are callsites in the monolith that don't use the opener button, and instead call showModal directly. We could have overridden that but it was deemed a risky change. This was discussed here: #3144 (comment). In this discussion I pointed out that once whatwg/html#9733 lands then we could use beforetoggle to reliably find a point in time just before the dialog opens, but this is a more complex fix.

So, fast forward to today; beforetoggle and toggle exist in Chrome & Firefox, and have recently been merged in Safari. I have a polyfill available to support browsers which don't support these events, which works reliably.

So this PR refactors the dialog helper to use beforetoggle to set the --dialog-scrollgutter. It brings in the polyfill to ensure cross-browser-compat.

Additionally, our dialog-helper code uses a MutationObserver to force dialogs to be shown as modal, not as non-modal. This takes the opportunity to use the toggle event to do this instead. This will have a far smaller impact on performance than the change using beforetoggle, but it certainly helps and makes the code cleaner & more readable.

Screenshots

Integration

List the issues that this change affects.

Risk Assessment

• Low risk the change is small, highly observable, and easily rolled back.
• Medium risk changes that are isolated, reduced in scope or could impact few users. The change will not impact library availability.
• High risk changes are those that could impact customers and SLOs, low or no test coverage, low observability, or slow to rollback.

What approach did you choose and why?

Anything you want to highlight for special attention from reviewers?

Accessibility

• No new axe scan violation - This change does not introduce any new axe scan violations.

Merge checklist

• Added/updated tests
• Added/updated documentation
• Added/updated previews (Lookbook)
• Tested in Chrome
• Tested in Firefox
• Tested in Safari
• Tested in Edge

Take a look at the What we look for in reviews section of the contributing guidelines for more information on how we review PRs.